the best solution would be to display these error messages directly in the Console.

Can we do both? I mean always display these messages in the console in that peculiar condition, and also show them in the message box when the Details button is pressed?

It might look redundant, but the OpenOCD console might not be on top to be easily visible and some users might have difficulties to open it, therefore the graphical solution is pretty convenient.

Both will be great, if it is possible.

Hello everyone,
I actually considered this point as well. The reason I didn’t opt to send the message to the console has to do with how the console output logic originally works. It’s worth noting that in the case of a timeout exception, no output is currently generated — following is the reason. O_O

The above describes the startup process of GdbServer.
step 1 : the launch sequence for GdbServer (OpenOCD) is obtained.
step 2 : This sequence is then executed, which includes starting the OpenOCD process, launching the timeout detection process, and more.
step 3: When the timeout detection process is triggered, it sets the status of the rm (RequestMonitor) to ERROR. This in turn causes an ExecutionException to be thrown, leading to the entire launch process being cleaned up and terminated, resulting in the well-known timeout error.

This is because the OpenOCD process (actually the pushback process) is only submitted to DSF and its output is bound to the console during step 4, when ((Launch) launch).initializeServerConsole(monitor); is executed. Therefore, if a timeout exception occurs, the entire debugging session terminates immediately, and step 4 is never reached. As a result, neither the console nor the process actually exists at that point, which explains why no error message is displayed.

Regarding displaying the error in the console:

Below is how ((Launch) launch).initializeServerConsole(monitor); is used to attach a console.

However, in the OpenOCD timeout detection task, using DebugPlugin.newProcess() as a way to output to the console is not appropriate — because we don’t intend to keep this process alive (in fact, it will be killed immediately by the timeout detection task 😂).

Therefore, I think we should consider using Eclipse’s console-related APIs to create a temporary console and display the final message to the user. The downside is that creating a temporary console would introduce some code that looks somewhat redundant, and it would require importing the org.eclipse.console package, which feels quite out of place.

Creating a temporary console and displaying the output would look something like this:

I have difficulties to follow the details, things seem to get very complicated. :-(

@ilg-ul
Sorry, I might have gone into too much detail. In short, I just wanted to explain why no output is shown on the console in the case of a timeout. You can think of it this way: when a timeout occurs, the entire debugging session is immediately terminated. At that point, the OpenOCD console hasn’t even been initialized yet, so there is no console or output — only the error message is triggered. 😊

At that point, the OpenOCD console hasn’t even been initialized yet, so there is no console or output

Can we initialize the console earlier, and, when the exception is identified, retrieve the console output and print it?